1. Field of the Invention
The present invention is generally related to electronic messaging and in particular, to electronic messaging in a networked environment.
2. Description of the Related Art
Modem businesses rely heavily on computer systems. Businesses frequently need one computer system to communicate with a second computer system, or for one application to communicate with another.
Unfortunately, computer systems, operating systems, and applications often lack sufficient uniformity to allow the communication to easily occur. One of the problems that has been encountered is that different computer systems, operating systems, and applications often use different and incompatible formats and messaging standards, i.e., one computer does not speak the other computer's language. The problem can be exacerbated as platforms shift, applications and equipment become obsolete, standards change, business partners change, and so on. Proprietary message definitions are also common and can also result in incompatible message formats between systems.
One technique for addressing this problem is to use software, often termed “Middleware,” that converts or maps an inbound message from a first system to an outbound message for a second system. After conversion, the outbound message is readable by the second system.
Conventional middleware solutions have many drawbacks. Conventional middleware systems map an entire inbound message to an inbound message structure in one large resource intensive step. When the inbound message is relatively large, e.g., several megabytes, mapping of the inbound message can consume a relatively large amount of memory for a relatively long period of time. When the system is busy mapping a large inbound message in one long step, the system may not be able to service a smaller, but higher priority message in an acceptably prompt manner.
A further disadvantage of a conventional middleware solution is that data in the inbound message structure can be difficult to extract. Conventional middleware solutions follow a simple, but rigid, set of rules that maintains data only in leaves of a tree structure hierarchy. Nodes of a conventional middleware solution do not contain data. Hence, when a user or another system desires to access data, the user navigates up and down through the tree structure hierarchy until the leaves with data are found. The process can be frustrating and time consuming.
A further disadvantage of conventional middleware solutions is that the structure of the mapping operation is predefined and inflexible. Thus, a system analyst predicts all combinations of mapping structures and creates those structures. When an inbound message does not correspond to an existing predefined structure, the system analyst creates a new mapping structure to facilitate the mapping of the inbound message. As a result, the system stores a myriad of mapping structures and when needed, the system tests each structure for compatibility with the inbound message.